home *** CD-ROM | disk | FTP | other *** search
-
- > Id said themselves that they could've made Jag DOOM about twice as fast.
- > I doubt they intended to rewrite much of the C code into assembly even then.
- > Those RISC chips are not bad at all.
-
- Well, they've got absolutely excellent divide instructions (32 bit integer by
- 32 bit integer -- or -- 16.16 realnumber by 16.16 realnumber in just 32 cycles,
- or 2 cycles per bit). Not as fast as the Falcon's one cycle per bit DSP divide,
- but the 32-bit range and realnumber fixed-point capability makes up for it.
-
- They also have excellent single-cycle multiply & shift instructions, but
- beyond that, everything else in there is just plain crap!
-
- And that's before you even start on the bugs...
-
- > It seems the graphics are mostly taken care of, as are AI, menus, music
- > and the WAD editor. Still, there must be something...
-
- There is still no real WAD management and no memory management. It's the
- only thing stopping me from writing the graphics cache, and I have not
- yet managed to get the time to make a real start on it. We really need
- some kind of block-based or auto-defragmenting memory model in order to
- cache the textures & sprites from disk, as 4MB probably won't hack it after
- the screenbuffers and everything else have been accounted for.
-
- We really need 3 screenbuffers to keep things smooth, and to reduce
- loss of CPU resouces between frame-swap roundoffs. Otherwise, I'd throw
- one of them in the bin.
-
- The only reason I haven't asked somebody else to help out with the WAD /
- memory stuff is because the memory management really needs to be written to
- suit the graphics cache - rather than the other way round - otherwise we could
- end up with a heavily fragmented, badly thrashed or generally very slow cache.
-
- We just can't coordinate very well because we all have work to do in the
- real world, and it's a case of getting done what you can as soon as you can.
-
- :I
-
- Doug.
-
-